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TANA Considerations for Three Letter Acronyms 
Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents in effect on the date of 
publication of this document (http://trustee.ietf.org/license-info). 
Please review these documents carefully, as they describe your rights 
and restrictions with respect to this document. 


This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
outside the IETF Standards Process, and derivative works of it may 
not be created outside the IETF Standards Process, except to format 
it for publication as an RFC or to translate it into languages other 
than English. 


Abstract 


Three Letter Acronyms (TLAS) are commonly used to identify components 
of networks or protocols as designed or specified within the IETF. A 
common concern is that one acronym may have multiple expansions. 
While this may not have been an issue in the past, network 
convergence means that protocols that did not previously operate 
together are now found in close proximity. This results in 
contention for acronyms, and confusion in interpretation. Such 
confusion has the potential to degrade the performance of the 
Internet as misunderstandings lead to misconfiguration or other 
operating errors. 
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Given the growing use of TLAs and the relatively small number 
available, this document specifies a Badly Construed Proposal (BCP) 
for the management of a registry of TLAs within the IETF, and the 
procedures for the allocation of new TLAs from the registry. 


1. Introduction 


A Three-Letter Acronym (TLA) is a popular form of abbreviation 
usually based on the initial letters of a three-word term. A formal 
definition of a TLA is provided in Section 2. 


TLAs are particularly popular within the Internet community where 
they serve as abbreviations in the spoken and written word. As their 
popularity has grown, the measure of the value of an RFC (q.v.) is 
not only its successful implementation, interoperability, and 
deployment, but also the number of TLAs included in the text. 


For example, the Transmission Control Protocol (itself a TLA - TCP) 
[RFC0793] is extremely successful. The specification contains no 
fewer than 20 distinct TLAs (although it should be noted that some 
are simple abbreviations rather than proper acronyms). On the other 
hand, the Internet Stream Protocol Version 2 [RFC1819] is ambiguously 
referred to using the TLA ST2, and also as STII which is clearly not 
a TLA. Further, the STII specification contains only 12 distinct 
TLAs, and it should be no surprise that STII has been far less 
successful than TCP. 


A common concern amongst diligent protocol implementers is that one 
acronym may have multiple expansions. While this may not have been 
an issue in the past, network convergence means that protocols that 
did not previously operate together are now found in close proximity. 
Not only does this result in contention for acronyms, and confusion 
in interpretation of specification, it also leads to many wasted 
hours trying to select appropriate and suitably-unique names for 
variables within source code implementations. Such confusion has the 
potential to degrade the performance of the Internet as 
misunderstandings lead to coding errors, compilation failures, 
misconfiguration, and other operating errors. 


Furthermore, it should be noted that we are rapidly approaching World 
Acronym Depletion (WAD). It has been estimated that, at the current 
rate of TLA allocation, we will run out by the end of September this 
year. This timescale could be worsened if there is the expected 
growth in demand for mobile acronyms, IP-TLAs, and TLA-on-demand. 
According to the definition provided in Section 2, there are 36**3 - 
10**3 = 45656 TLAs in total. This number will so easily be depleted 
that we must institute some policy for conservation. 
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The Internet Assigned Numbers Authority (IANA, helpfully, a four- 
letter acronym - although note that a four-letter acronym is an FLA 
and hence is, in its own way, a TLA) maintains registries of names 
and numbers for use within the Internet in order to avoid duplicate 
allocation of one of those names or numbers and the consequent 
confusion and failed interoperability that would arise. It is, 
therefore, wholly appropriate that the IANA should manage the 
assignment and use of TLAs within the Internet. 


This document specifies a Badly Construed Proposal for the management 
of a registry of TLAs within the IETF, and the procedures for the 
allocation of new TLAs from the registry. 


1.1. RFC Editor Terminology List 


It is worth observing that the RFC Editor currently maintains a list 
of common terms, abbreviations, and acronyms. While this list is 
highly useful for the construction of documents, it does not provide 
unambiguous interpretation of acronyms. 


2. Formal Definition of TLA 


Acronym - a word made up of the initial letters of the words in a 
phrase. 


For example, IETF is an acronym formed from the first letters of 
the phrase International Essential Tremor Foundation [URL-IETF]. 


Three Letter Acronym (TLA) - an acronym comprising exactly three 
letters. 


For example, RFC is a TLA formed of the first letters of the 
phrase Rugby Football Club [URL-CARDIFF]. 


For our usage, we also allow digits within a TLA. Thus, P2P is an 
acronym meaning Purchase to Pay [URL-P2P]. The digits 2 and 4 are 
specially used by clever people who have noticed that, when spoken, 
they sound like the words ’to’ and ’for’. Whether this is helpful 
may be left as an exercise for the user considering the brief 
conversation, below. 


- Do you use the Internet Streams Protocol? 

- Yes. Do you use ST, too? 

No, I use ST2. 

- That’s interesting. C uses ST2, too. 

- I have a car horn application called Toot-toot. 
- Really? Do you use ST2 to Toot-toot, too? 


Drone w pe 
l 
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Note, however, that an acronym made up entirely of digits might be 
frowned upon. 


Lastly, we must consider case-sensitivity. Although acronyms often 
include upper or lowercase letters, no assumptions should be made 
about the interpretation of the acronym based on the case of its 
letters, so that both QOS and QoS clearly refer to the Queen of the 
South football club [URL-QOS] and [URL-QoS]. 


2.1. A Note on Vocalization 


Acronyms are often articulated as words in spoken text. This can be 
helpful in generating a cosy feel or a marketing buzz around a 
concept that offers a less-favorable reality. For example, Claws and 
Teeth (CAT) can be pronounced "cat" making it seem quite cuddly. 


Other acronyms are always spelled out in order to avoid accidental 
misinterpretation or litigation. For example, do not refer to your 
neighbor’s Daughter or Granddaughter as anything other than their 


D-O-G. 

But care should be taken with vocalization, as well. It will be 
noted that some letters have more syllables than the words they are 
used to represent. In these cases, acronyms are to be avoided. 


Thus, the world wide web must never be assigned the acronym WWW. 


Finally, a word of caution about attempting to pronounce acronyms as 
words. This can lead to serious injury for the inexperienced unless 
they happen to be native speakers of Czech. Do not try to say XML in 
front of your mother-in-law, and don’t attempt to talk about Open 
Office dot Org in polite company. 


3. Backward and Forward Compatibility 


It should be obvious to most RFC readers (MRRs) that TLAs are already 
widely used in Internet specifications. This work is not intended to 
unnecessarily invalidate existing RFCs, although where such 
invalidation is necessary or desirable, this work can be used for 
that purpose. 


In order to support existing documents, IANA is required to search 
all existing RFCs for every existing acronym usage (EAU), but may 
filter that search to exclude non-TLAs. 


It will be noted that, as a result of that search, many duplicate 
meanings will be discovered. For example, "OAM" will be found ina 
large number of RFCs, yet its meaning may be as diverse as "on a 
mission", "order of Australia medal", and "orbital angular momentum". 
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This contention is best resolved by the judgement of Solomon -- each 

acronym usage will be allocated its share of the letters currently in 
use. If there are three uses of an acronym, they will get one letter 
each; two existing uses would get one-and-a-half letters each; etc. 


4. IANA Considerations 
4.1. New Registry 


The Internet TLA Registry (ITR) should track the following 
information: 


- TLA 
- Unique interpretation 
- Defining RFC 


4.2. Reserved Values 


Certain key values are reserved. That is, they are allocated in the 
registry by this document and may not be used for any other purpose. 


Acronym Expansion Reference 
ER ENEE 4+----------- - - tt er 
TLA Two Letter Acronym [RFC5513] 
TBD Two Be Deleted [RFC5513] 
REC Ready for Compost [RFC5513] 
Pos Not particularly good [RFC5513] 
VPN Very possibly no use [RFC5513] 
TCP Totally bad proposal [RFC5513] 
USA Universal Source of Acronyms [RFC5513] 
NBG This document [RFC5513] 
BCP Badly construed proposal [RFC5513] 


4.3. Allocation Policy 


IANA shall apply the following allocation policies according to 
[RFC5226]. 


Experimental Use 
All TLAs of the form XX* where * is any letter or digit. 


First Come First Served 
All TLAs of the form X**, Y**, or Z** where * is any letter or 


digit. Excepted from this are the TLAs of the form XX* as above. 


IETF Review 
All other TLAs. 
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5. Security Considerations 


Many security algorithms are identified by TLAs. It is a clear 
requirement that someone implementing, for example, MD5 should be 
understood to have encoded the well-known Maybe-Decrypted- 
Deciphered-Decoded-Disambiguated-and-Degraded algorithm, and not any 
other security algorithm with the same acronym. 
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